NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/17929

Internet Message Format | 1996-08-05 | 7.1 KB

Path: news.nstn.ca!news
From: [e-mail] (dbshapco)
Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
Subject: More OOA (was:Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer)
Date: 18 Apr 1996 04:31:01 GMT
Organization: iSTAR Navigator User
Message-ID: <4l4gi5$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <4kkkbm$[e-mail]> <[e-mail]> <4kma54$[e-mail]> <[e-mail]> <4l3auv$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: ts2-14.ott.istar.ca
Mime-Version: 1.0
X-Newsreader: WinVN 0.93.14

In article <4l3auv$[e-mail]>, [e-mail]
says...
>
>In article <[e-mail]>,
>[e-mail] (William D. Gooch) writes:
>
>OTOH, it is interesting that it is in GUI/window development that
>O-O methods have been *generally* regarded (even by skeptics) as most
>successful.  So, perhaps, there is some significance after all to such
>correspondence.  At least, if what you care about is actual productivity,
>rather than an O-O religious experience.  Now, in some applications,
>the GUI is 99% of the app, but in others, I can assure you that it is
>less than 1%.  It may simply be the case that O-O methods are more
>effective, pragmatically speaking, for the former case than for the
>latter.  Why insist on applying the same techniques to every problem?
>[cliche' of the day: "If the only tool you have is a hammer,
>everything looks like a nail."]

Software engineering lacks the conventionalized techniques and terminology
developed with centuries of practise in other fields such as architecture or
mechanical engineering, and often even the conventional terminology and
conceptual foundations that allow an architect to discuss with relative ease
the problems of live loading on a building structure with an engineer.

GUIs however seem to become one of those areas that are (now) highly
conventionalized and easy to analyze because the problem in fact was
decomposed into a metaphorical framework at Xerox Parc over a decade ago.  No
reasonably computer literate person needs the concept of a window explained
to them.

Often I've witnessed software development teams accepting the tandem problem
of decomposing an unconventional and original problem and learning new
techniques and technologies for doing so.  The novelty of both have negative
symbiotic effects on each other.  The relativity immaturity of software
engineering further complicates the task.  It is often difficult to
communicate the foundational concepts to team members of varying levels of
training and understanding, and managers and team leaders haven't the
experience to tailor roles, training and responsibilities appropriately.
This is a recipe for disaster, and the price of failed software projects,
cost overruns and late delivery is estimated in the Saganesque billions and
billions per year in North America.

GUIs by now are as much a cooked and 'toy' problem as those found in
introductory OO books -- there exist straightforward and automatic
decompositions of the problem into classes and class hierarchies, and in fact
many GUI frameworks representing pre-fab applications.  They possess another
attractive attribute -- they are highly visual and therefore susceptible to
the architectonic (~spatio-temporaral) analysis that many engineers,
mathematicians and computer scientists excel at (who tend to be the people
doing software development).

This does not mean that OOT fails at unconventional problems, but that many
fail to recognize that with such problems an extra step is involved in
decomposing the problem into appropriate elements at an appropriate level of
abstraction.  This happens in architecture, mathematics, science, engineering
and so on -- these fields usually just have frameworks handed down from
decades or centuries of practise, a legacy either software engineering
doesn't enjoy or isn't recognized by undertrained practioners.  Software
engineering is also an applied science, which requires appreciation of the
domain to which it is applied.  Most of us have so long used and played with
and programmed GUIs that we can consider ourselves de facto 'domain experts'.
Confronted with other domains, developers often fail to recongize the need
for this domain expertise.

What I find *consistently* are software teams that employ OOADP to describe a
linear, structured solution to their problem.  Having typically 1-12 years
experience solving problems in software their minds have been trained to
operate this way.  Like breaking away from any habit, those adopting OO are
going to find their technique suffers until OO becomes natural -- the new
habit replacing the old.  You can teach people all the OOADP you want, and
without integrating the new thinking into their work they can readily bend
all that teaching to developing and describing old-style solutions.  OOT can
only support, and not enforce, the new paradigms.  And BTW, OOADP introduces
awful and needless overhead and complexity into linear, structured software
solutions, so that people who abuse OO (as I said in an earlier post) come to
blame OO for introducing awful and needless overhead and complexity.  It is
fairly difficult to describe a blueprint for a building using calculus
notation or Lisp syntax, but that isn't a failing of calculus or Lisp.

The great divide in OO separates those who understand the notations, the
languages, and the jargon and those who've grokked the fundamental paradigm
shift (a la Kuhn).  This might actually get back to the subject that started
this thread an era ago: a mind trained to one paradigm (the, let us say
somewhat archetypal, C hacker) more strongly resists the new paradigm than
the tabula rasa.  I think that is Bertrand Meyer's hypothesis, and not an
established fact, and even if true the C hacker archetype also carries many
other skills and qualities that might outweigh this disadvantage.

Most people need to recover the architectonic thinking so natural to them and
discard training forced upon them by a more primitive level of technology.
Use Cases can be taught in a three day course, OMT a four day course, C++ or
Eiffel a four day course, but getting people to again trust themselves and
their natural patterns of thought after years of shoehorning their thinking
into unnatural patterns to accomodate the technology is bloody difficult
(IME).

OOT's power is that it supports natural ways for humans to reason about
problems, and by notation to communicate that reasoning to other humans in
reasonably natural form.  But all the computer still understands is opcodes,
and all technologies only add notational or expressive power *for the benefit
of humans*.  And I might claim that OO has higher general notational and
expressive power across a wider spectrum of domains than other technologies.


--
Brad Shapcott, Technical Consultant
Lockheed-Martin's Advanced Concepts Center
Ottawa, Canada [phone] x227